Please could you fix some little bugs in this request?

• monitor is mis-spelt
• some possible out-by-one bugs in the comparisons against top of memory
• please always use 0xffff in preference to using 65536 (or 65535)

I've fixed 1 & 3. However, I don't see what you mean by "one-off errors in the comparisons against the top of memory". From the easy6502 page:

Thee 6502 uses a 16-bit address bus, meaning that there are 65536 bytes of memory available to the processor. Remember that a byte is represented by two hex characters, so the memory locations are generally represented as $0000 - $ffff. There are various ways to refer to these memory locations, as detailed below.

The reason why I'm using 0x10000 is because length does not start from zero. For example, you could only want the monitor to display the very last word in memory. To do so you'd specify a start of $ffff and a length of 1. If the upper limit was 0xffff then start + length would exceed it, even though this is a valid range.

Oops, you are quite right - it was my own out by one error. Noting that I have seen your request to use start and end instead of start and length, I wonder if it would be clearer to use
(start + length - 1) <= 0xffff
If you don't agree, just let me know and I'll merge as-is.
If you do agree, please make the corresponding tweaks, and I'll merge.
Thanks!

I agree. I've made the changes. I think this way (the way you proposed), is a lot easier to think about.

That's great - merged. I'm trying to keep this (original) fork as stable as possible, in a strict maintenance-only mode. I intend to put a note into the page and the readme to promote any other actively-developed forks. The idea is that anyone landing at http://skilldrick.github.io/easy6502/ will have something worthwhile to use, and also have pointers to more advanced developments. The various active forks will of course be free to share their innovations amongst themselves, and no-one need be held up by my caution or inattention.

So you recommend moving Issues #11 #13 #18 and #19 into my own fork instead trying to PR them here?

#11 I'd like to get fixed, but yes please, let's regard the others as enhancements to your fork.